Within the financial industry, document processing is an important part of the daily management of a business. Document processing systems include sorters for physically handling and retrieving data from checks and other items and data processors for analyzing and storing the retrieved data. The sorters and data processors intercommunicate data and instructions to individually read and process each check.
Conventional check sorters for document processing, such as the IBM 3890 and 3890/XP series of check sorters, are relatively large and expensive machines. Thus, purchasing one of these check sorters may place a great financial strain on a small business or may be unreasonable for a larger business needing to process a relatively small number of checks over the business' current capacity. Smaller and less expensive check sorters typically cannot communicate with existing data processing systems that are designed to operate in connection with the IBM 3890 and 3890/XP series of check sorters. As a result, the smaller check sorters are not a viable solution in many applications.
Attempts to solve this problem have included customized emulators which allow a specific check sorter, which may be smaller and less expensive, to emulate the IBM 3890 and 3890/XP series of check sorters so that the data processing system may communicate with the specific check sorter. However, these emulators are hardware-specific solutions. Thus, a different emulator must be designed, programmed and proved out for each different type of check sorter. This customization is time-consuming and expensive and is thus not a practical solution.
Both traditional and customized document processing systems typically use LU 6.2 or channel connect standards to connect to and to communicate with a mainframe running the data processor. These types of connections are expensive to configure and maintain and this limits the viability of these systems.
Yet another disadvantage relates to code line data matching. Typical sorters, and typical emulators as well, provide approximately sixteen lines of memory for code line data matching, which may be used to save time when processing a document for a second time. This limited amount of memory allows data to be saved for a relatively small number of documents. In addition, the processor that searches the memory for code line data matches is generally not fast enough to allow the memory to be expanded. If more lines of data were available to be searched, the processor would not have enough time to search the additional lines of data before the amount of time for processing the document had expired.